There is some trickiness in handling CFM version numbers and the various development environments.
Each sample maintains a <PartName>Vers.h file which defines the CFM version numbers for the part class being written. Unfortunately, the information provided in the file is not available everywhere. This means that you, the part writer, will have to make sure the information in the file, when it changes, is in sync with the version numbers in the makefile, and perhaps the project file.
To complicate matters, the version number used by CFM has the same format as Finder's vers resource. This is a long generated from a hex digit and 2 BCD digits. If you look at the CFM version number in the CodeWarrrior project for SamplePart, you will notice the number 16809984 (or something similar). This number represents translates into "1.0.0 GM" (in Rez speak). An easy way to obtain this number is to use the MPW DumpPef tool on your part library (assuming the CFM version numbers are set correctly in your makefile) after a build. The DumpPef tool will display the PEF container header which contains the "current implementation version" number.
Number 2 ( Debugging )
Source level debuggers that rely on the "Power Mac DebugServices" application will have trouble targeting parts if their Library name, sym files name, and one of the Code Fragment names, are not all in sync.
Please read the “Debugging OD Part Editors” document to get the fine details.
Number 3 ( System Object Model™ (SOM) compiler )
The SOM compiler/emitter is a bit overzealous in its attempt to "update" sources files. Be forewarned that if you run the IDL compiler more than once over the same file, the compiler will update function headers that it "just doesn't like" (those with parms commented out) and will most definitely "add" any missing function headers (Warning to all of us who have the SOM class implementation split across source files).
